Any telephone call progresses through a series of steps from beginning to end. Each step is identified with a state or status of the call, and the progress from one step to the next in a call is termed a transition. For example, a subscriber picks up a phone handset to make a call, and the call shifts from an idle state to a dial tone (‘tone’) state. When the subscriber begins to dial or press in a number, the call shifts from the tone state to a dialing (‘dial’) state. When the switching network locates the called line and begins sending ring signals to the receiving phone, the call state shifts from ‘dial’ to ‘ringing’. This process continues until the call is ended and the state returns to ‘idle’. These changes from state to state are the transitions of the state of the call.
In conventional call processing technologies, all the system intelligence for processing telephone calls has resided in the central switching element, for example, the High Density Exchange (HDX), a high-density version of the system originally covered in U.S. Pat. No. 4,228,536, said patent incorporated herein by reference, and hereinafter referred to as “the '536 patent”. The endpoint instruments in conventional call processing have been ‘dumb’, i.e., they do not contain any call processing elements.
Central switching elements in conventional call processing are not restricted to single physical components. For example, in systems using Modular Switching Peripheral (MSP) architecture, also known in the industry as Computer/Telephony Integration, or CTI, the MSP together with the host computer constitute the central switching element. Although ISDN (Integrated Services Digital Network) telephones have some intelligence, call control still resides almost exclusively with the central switching element.
VoIP transforms the conventional switching architecture. Simply by purchasing some VoIP telephones and connecting them to an existing Ethernet LAN, a provider can construct a basic VoIP telephone network. The provider can configure the phones either manually or through a simple Web-based interface. As a result, the provider can supply a private phone system without any special software or hardware anywhere else in the network, so that the phones can dial, ring, and talk to one another. In such an architecture, the phones contain all the intelligence needed to make the VoIP network operate.
As the VoIP system scales up in size, it obtains advantages from the reintroduction of a central switching element to facilitate system administration and provision of certain features. But in contrast to practice in conventional telephone networks, the reintroduced central switching element, often called a Call Manager or LCC (Local Call Controller), operates with the VoIP phones principally at a peer-to-peer level.
Integrating a VoIP system with a mature, complex, and feature-rich system utilizing centralized call processing, such as the HDX platform, presents unique challenges. Attempting to integrate existing centralized call processing logic with decentralized VoIP call processing makes control of a call an issue between the central switching element and the telephone itself.
Call processing is implemented using a finite state machine (FSM), a design structure well-known in the art, in which a call is always in one of a finite number of discrete states (e.g., Dialing, Ringing, Talking, and others), and an event occurring in the system can trigger an action to cause the call to progress from one state to another.
The HDX call-processing FSM, also called Port Event Processing (PEP), currently has hundreds of call states and thousands of software components used for processing the events which occur in each of these states. The integration of VoIP with the HDX would, under the application of ordinary skill in the art, require a system builder to rework most of the software components comprising the FSM (PEP).
The conventional way to implement a new feature within a call processing FSM is to begin by examining carefully each and every call state, event, and transition routine. “Transition routine” is the name for the actual code which executes when a given event is received for a port in a given state. A transition routine performs some action appropriate to the event and the current state, and its action may include a transition to a different state.
The next step in conventional feature implementation is the design and implementation of code for one or more existing transition routines, and possibly the addition of new states and events as well, together with new transition routines to process the new states and events. Every state transition in the FSM represents added exposure to potential software bugs whenever an incorrect modification is made in support of the new feature, or whenever a required change is erroneously overlooked. The large number of state transitions therefore makes feature implementation in the conventional way a highly error-prone task, raising its cost considerably. Avoidance of such extensive rework of software would be highly advantageous.
Furthermore, PEP/HDX integration, done properly, would other providers a clear, smooth path between powerful, well-established, but less-flexible conventional call processing systems and the highly-flexible VoIP systems offering all the potential of the Internet. Opening such a path would grant telephony system providers clear advantages over either technology alone.